I see this as the opposite. An Operation is an action the API/Application performs. For example, if the action is send, It means the application API defined in the current AsyncAPI document is sending a message.

I would never say, that an API performs some operation, as the API is just the description of the interface that is implemented by some application. I am on the same side with the direction of send and receive. I could add something like "Operations are always described from the point of view of the application." to make it clearer in which direction send and receive take their effect. (I was hoping that the context of the first sentence would make this clear already.)

Yeah, you are right about the API term. However, I'm confused about the meaning of this sentence then:

a specific action an application can take to interact with the message-driven API

So you mean the application which defines the Application API through the AsyncAPI Document takes actions to interact, but with who?
I think the issue is more on the with the message-driven API part. Maybe with the users of it's API or similar will make it more clear?
I leave this for you so you can come up with a better alternative than me (for sure).

Yeah, this is the tricky part. An AsyncAPI spec can describe operations for "consumers" of an API or for "providers" of an API. Especially with async APIs it is not always clear if an application is a pure consumer or provider of the API. The spec intentionally allows to document both kinds of applications.

This has language for both applications but is potentially more confusing:

a specific action an application can take to interact with or implement part of the message-driven API.

Or we state explicitly with whom the application interacts:

a specific action an application can take to interact with other sender or receiver applications [through the message-driven API].

I understand that the message-driven API term is confusing as it does not have a clear definition. I think that we should have a definition for that term (at least in the context of an AsyncAPI file), but that is a separate issue.
The AsyncAPI document clearly defines some kind of API. I would suggest calling the sum of all operations a view of (or a part of) the message-driven API (or interface) of the application.

An AsyncAPI spec can describe operations for "consumers" of an API or for "providers" of an API. Especially with async APIs it is not always clear if an application is a pure consumer or provider of the API. The spec intentionally allows to document both kinds of applications.

Since v3, this statement was added:

The AsyncAPI document SHOULD describe the operations an application performs.

Source: https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md?plain=1#L19

Wouldn't we just document from that point of view as the standard? Honest question.

I agree. I just wanted to point out that the application can have an operation sendLoginCredentials (I would call this application a consumer/client of an API) while another application will have receiveLoginCredentials as operation (providing the API). Both applications can be described in an AsyncAPI document.

The AsyncAPI document SHOULD describe the operations an application performs.

Wouldn't we just document from that point of view as the standard? Honest question.

If this is one of the core principles behind AsyncAPI, then we should make this more prominent. Currently, I feel that it is often unclear if an AsyncAPI document describes an API, an Application, a set of Channels/Operations, or even a system of multiple Applications. While this sentence addresses this confusion, it is not enough. Repeating this information in a definition for "AsyncAPI [document]" would help improve its visibility.

As for this PR: I am currently leaning towards the second option, as it concretely describes what an operation is used for without referencing an API.
I will make this change later today (and also update the toc):

While this sentence addresses this confusion, it is not enough. Repeating this information in a definition for "AsyncAPI [document]" would help improve its visibility.

I can agree this is not be super cristal clear. I invite you to open a new issue so we can work on it; happy to push it forward.

The point is that it is a fact, one single AsyncAPI document should describe no more than one application. An exception to this, would be an AsyncAPI document with all definitions located under components. That would be considered as a "menu" of components, such as channels, servers, operations, which can be reused by those individual AsyncAPI documents. At the end, that file could be describing your broker.

I will probably open an issue for this once this PR is merged. I have updated this PR to my suggested change above.

There is one more case: Multiple AsyncAPI documents may be used to describe different APIs of the same application (e.g., public facing API vs. internal API). So it is not 1 to 1 for AsyncAPI document to application.

So it is not 1 to 1 for AsyncAPI document to application.

There is no limitation on the number of documents. We talk about 1:1 because it's the most common scenario. But it all depends on how you want to expose those AsyncAPI documents to the users.
AsyncAPI spec doesn't limit anything on that side.